Don't cancel other jobs from the 3.12 job failing #93
Conversation
Because 3.12 is still a release candidate and if tests fail for it then one would always want to know if/how other versions also fail. This also allows actions/setup-python to install a prerelease for 3.12 only, not for other releases.
|
Thanks! Yes, I used the same pattern in gitpython-developers/GitPython#1654, though (in my mind) not entirely for the same purpose. Here in gitdb's workflow file, In contrast, GitPython's roughly corresponding workflow file explicitly sets |
This updates smmap's CI configuration in ways that are in line with recent updates to gitdb's. In most cases there is no difference in the changes, and the reason for the updates is more to avoid confusing differences than from the value of the changes themselves. In one case, there is a major difference (fetch-depth). - gitpython-developers/gitdb#89 (same) - gitpython-developers/gitdb#90 (same) It's just the project, not dependencies, but otherwise the same. - gitpython-developers/gitdb#92 (opposite) This is the major difference. We don't need more than the tip of the branch in these tests. Keeping the default fetch-depth of 1 by not setting it explicitly avoids giving the impression that the tests here are doing something they are not (and also serves as a speed optimization). - gitpython-developers/gitdb#93 (same)
Because 3.12 is still a release candidate and if tests fail for it then one would always want to know if/how other versions also fail.
Note that a failure of the 3.12 job will still be treated as a failed check and will still cause the workflow to be considered to have failed, which we probably want. Setting
continue-on-errorfor the job just overrides the default matrixfail-fastbehavior, so the 3.12 job won't cause other jobs from the matrix to be cancelled if it fails. (Other jobs will still cause cancellation.)I used a technique based on the one in the GitHub Actions documentation, but modified so all versions can be listed in one place and so the automatically generated job names remain short, as they were before.
This also allows
actions/setup-pythonto install a prerelease for 3.12 only, and no longer for other releases. (This is less important, because only under very strange circumstances would only an old prerelease of a stable release be available to the CI runner. But treating 3.12 specially, as above, allows this to be done too, with no increase in complexity.)This may or may not be considered worthwhile, given that it should be undone sometime not long after the stable 3.12.0 comes out. However, I think the
allow-preleasesoverride totrueshould be undone at that time, so it seems to me that the burden is much the same either way (and the stakes very low, either way, if it is left in place too long).